This invention relates generally to the field of computer systems. More particularly, a system and method are provided for enabling an application server to serve an enterprise application over multiple protocols, such as telnet and HTTP.
Enterprise Information Systems (EIS) provide information infrastructures for an enterprise. Example EISs include an Enterprise Resource Planning (ERP) system such as the Oracle E-Business Suite, a mainframe transaction processing system, a relational database system, and so on.
The J2EE Connector Architecture (JCA) facilitates integration of application servers with heterogeneous Enterprise Information Systems. JCA defines System-level Contracts that encapsulate important requirements for effective and scalable integration with EISs, such as connection management and pooling, transaction management to support transactions internal to an EIS and across multiple EISs, error logging and tracing, and a security framework enabling both container-managed and component-managed sign-on.
The EIS side of a System-level Contract is implemented in a Resource Adapter, which is specific to an underlying EIS. A Resource Adapter is a system-level software driver used by an application server (e.g., a J2EE application server) or an application client to communicate and operate with an EIS. While a Resource Adapter is specific to the EIS it represents, it is not specific to a particular application server and can therefore be reused across J2EE application servers.
JCA offers System-level Contracts (e.g., Message Inflow, Transaction Inflow) that specifically support asynchronous message delivery between EISs and application servers, from a wide range of message providers. Thus, JCA applications can benefit from simplified bi-directional communications with EISs.
Applications in the context of application servers are typically developed for a specific client communication protocol. For example, a warehouse or retailer may employ an application server to serve a legacy application, using the telnet protocol, for inventory control, shipping and/or other purposes. Employees may operate telnet-based client devices, which are relatively cheap and easy to operate. The client devices employ a terminal emulation program that provides a simple character-based user interface to its user and communicates with the application server using the telnet protocol. The legacy application may have been in use for a long period of time, and may work reliably with the relatively old devices.
However, newer, more powerful devices offering richer graphical user interfaces such as HTML (Hypertext Markup Language) browsers are available, many of which are able to support embedded peripherals (e.g., digital camera, printer, RFID scanner) that older, telnet-based, devices cannot.
And, due to the availability of powerful HTML browsers for desktop use, application servers have been enhanced to serve HTML applications over HTTP (HyperText Transport Protocol)—such an application may be referred to as a web application. At the same time, standards bodies such as the W3C (World Wide Web Consortium) and JCP (Java Community Process) have pushed many standards to promote the adoption of new technologies to improve the quality of web applications.
An application developed to be served to one type of client device via one communication protocol generally cannot simultaneously be served to devices employing other protocols. Thus, the legacy warehouse or retailer application above could not be served by the same application server to an HTML client over HTTP, just as a web application cannot be served to a telnet client.
To operate multiple types of devices in one application environment would require substantial redundancy—multiple application models, applications, server management procedures, installation procedures, etc. Thus, one application server would be deployed to serve the application to the telnet devices, while a separate application server would serve the application to HTTP devices.
An organization may naturally desire to upgrade its older devices or evolve its legacy application to add capabilities, but will want to avoid the inefficiency inherent in such redundancy. The organization may therefore wish to perform the upgrade in a phased manner, so as to continue using older client devices as long as possible and not lose its investment in the older technology. But, to facilitate this phased approach, the application server must be able to serve an application in multiple formats (e.g., telnet and HTTP).
Telnet-based clients use persistent connections, and can send a continuous stream of data to the server. There is no concept of a “complete request” from a device's telnet emulator. In contrast, HTTP-based clients generally use non-persistent connections, sending discrete requests via HTTP and receiving discrete responses. The request serves as a complete collection of information that the application server can process. Thus, an application server configured to serve an application using a request/response-type format (e.g., via HTTP) could not serve incompatible clients (e.g., telnet clients).
Currently, there is no easy way for a single application server operating with an EIS to serve one application to multiple devices configured for different types of service (e.g., telnet, HTTP). The current approach is to use different application servers, which makes it difficult to have a single application development model and to re-use a single application on telnet-based and HTTP-based devices.